Method and system with authentication, revocable anonymity and non-repudiation

ABSTRACT

The present invention relates to a method of access to a service consisting in i) identifying and registering a client (C), ii) authenticating the client to an anonymous certification authority, iii) authenticating the client by producing an anonymous signature and opening and maintaining an anonymous authentication session with a server (Se), and iv) selectively allowing contact between the server (Se) and the anonymous certification authority (ACA) to revoke the anonymity of the client (C) using the signature provided in step iii). The invention also relates to a system for opening and maintaining an authentication session guaranteeing non-repudiation.

This is a U.S. national stage of application No. PCT/DE2003/003380,filed on 14 Nov. 2003.

TECHNICAL FIELD

The invention relates to a method of secure access to services, inparticular to a method of secure access to data processing resources.

A general objective of the invention is to offer a strong and anonymoususer authentication service and a fast and economical mechanism formaintaining session authentication. Despite user anonymity, theinvention makes users responsible for their actions by offering to theresources accessed the possibility of revoking user anonymity ifnecessary (for example in the event of a dispute).

The invention may find numerous applications. Those indicatedhereinafter must not be considered as limiting the invention.

The major applications of the present invention are electronic biddingand networked/community games. In fact, the invention is particularlysuitable for any application whose object is to offer a public space inwhich a plurality of users may meet and communicate anonymously.

The invention is particularly pertinent in the case of electronicbidding, where the object is to reproduce the principle of real bidding,enabling persons gathered together in the same room to make bidsanonymously. Although their identity is never revealed, participantscannot repudiate their bids. The present invention offers the sameproperties of anonymous authentication and non-repudiation.

The same functions can also be used for multiplayer games applications,such as casino games, in which a plurality of persons gather around thesame gaming table without knowing each other. If a player bets on anumber, he is not able to repudiate the bet. The present inventionoffers these properties: it guarantees player anonymity (the identity ofthe players is not revealed) whilst making them responsible for theiractions (the identity of the players can be revealed if necessary).

DESCRIPTION OF THE PRIOR ART

The general object of the invention is to propose means for 1)guaranteeing the anonymity of clients, 2) maintaining an authenticationsession effectively, and 3) making clients responsible for theiractions.

A certain number of existing techniques satisfy some of the aboverequirements, but none offers a complete solution to the overallproblem.

Certain techniques enable a server to authenticate a client and aregenerally linked to a mechanism for maintaining an authenticationsession between the user and the server.

The following are the major techniques offering authentication andsession maintaining services: 1) one-time passwords, 2) the SSL and TLStechniques, and 3) the Kerberos technique.

One-time passwords: the principle of one-time passwords (OTP) is to usepasswords that can be used once only. Even if the password is revealed,it cannot be used again. In practice, this device generally takes theform of a card reader resembling a pocket calculator, for example anActivCard or SecurID card reader, which calculates passwords that usersmust enter to authenticate themselves. The password is then used tocalculate a session key (secret key) intended to guarantee theconfidentiality and integrity of communication.

SSL and TLS techniques: these techniques are based on certificates andpublic key (asymmetrical) cryptography algorithms for authentication andsecret key (symmetrical) cryptography algorithms for sessionmaintenance. A certificate constitutes a digital identity card. It takesthe form of a file containing a public key and information on itsproprietor. That information is certified (i.e. signed) by a trustedauthority known as the certification authority. To authenticate a user,a server typically sends him a challenge (a random numerical value) thatthe user signs using his private key. The public key enables the serverto verify that the user holds the private key and enables thecertificate to know the identity of the user. Moreover, thisauthentication stage enables the client and the server to exchange asession key (secret key) that will enable them to guarantee theconfidentiality and integrity of communication between them.

Kerberos technique: this is a single sign-on (SSO) mechanism enabling auser to access a plurality of resources without having to authenticatehimself more than once. It is based on secret key cryptographyalgorithms. To access a server, the user typically authenticates himselfto a key distribution centre (KDC) which sends him an authenticationtoken for the target server. The token is sent in a manner that istransparent to the target server and enables it to identify/authenticatethe user and to recover a session key (secret key) used by the serverand the client to guarantee the confidentiality and integrity ofcommunication between them.

The major drawbacks of the above prior art techniques are as follows:

The anonymity of users is not preserved: the authentication mechanismsof the above techniques are intended to verify the real identity of theclient. That identity is revealed by the login in the case of one-timepasswords, by the certificate in the case of the TLS and SSL techniques,and by the authentication token in the case of the Kerberos technique.

Non-repudiation is not guaranteed: the above techniques use secret keycryptography algorithms to maintain the authentication session and toguarantee the confidentiality and integrity of communication. That typeof cryptography algorithm cannot guarantee non-repudiation. The clientcan always deny having sent a message.

Maintaining the session is costly: the session is maintained byencrypting or authenticating the messages that the client and the serverexchange. The client must have calculation means available at all timesto maintain the session.

Other techniques offer authentication mechanisms that preserve theanonymity of users.

The use of a pseudonym is the approach most widely adopted by theservers currently deployed on the Internet (e.g. electronic biddingsites, games sites). This technique is based on an authenticationmechanism based on the use of a login name (i.e. a pseudonym) and apassword. Users generally register with the server by giving certainpersonal information and choosing a pseudonym and a password that theymust then enter to authenticate themselves. This approach gives rise toa certain number of problems:

Ergonomic problem: each user must register with each of the servers,which involves entering the same information several times.

Anonymity problem: personal information on users is stored on eachserver. The anonymity of a user is guaranteed with respect to otherusers but not with respect to the server. The user must therefore havetotal confidence in each of the service providers.

Identification and responsibility problem: information given by the useris not verified much, if at all. The user is authenticated but notstrongly authenticated. He can therefore enter erroneous information,pass himself off for someone else or register more than once usingdifferent pseudonyms. As a general rule, this approach cannot make theuser responsible for his actions, since the server is unable to proveanything.

Traceability problem: the server can track the activities of its clientsand can therefore deduce a profile that often constitutes information ofgreater benefit than a client's real identity. Thus anonymity is notcompletely guaranteed.

Group signature techniques (see documents [1], [2], [3] and [4]), usedin electronic bidding in particular (see document [5]), also offer ananonymous authentication mechanism. The general principle is for aclient to register with a trusted authority, constituting the groupmanager. Clients registered with that authority belong to the same groupand are provided with means for signing in the name of the group. Anyserver is provided with means for verifying a signature. Verifying asignature in fact consists in verifying that it was produced by a memberof the group and reveals no information on the member who produced itand therefore does not enable the server to find out the identity ofthat user. Thus the anonymity of clients is guaranteed. A server cannevertheless interrogate the group manager to revoke the anonymity of asignatory.

Thus the above technique addresses the problem of anonymousauthentication but does not incorporate any mechanism for maintaining anauthentication session between a client and a server. Thus the servercannot “remember” the identity of the client. To maintain theauthentication, the client must sign each of the messages that he sendsto the server and therefore must have the necessary calculation meansavailable at all times. Moreover, the calculations employed for applyingsuch signatures are relatively voluminous and therefore rule out fastauthentication.

SUMMARY OF THE INVENTION

An object of the invention is to provide a complete solution to theanonymous authentication and session maintaining problem.

The object cited above is achieved in the context of the presentinvention by a method that comprises the steps of:

i) identifying and registering a client and providing him with means forauthenticating himself to an anonymous certification authority,

ii) authenticating the client to the anonymous certification authorityusing the means provided in step i) and supplying means enabling him toauthenticate himself anonymously to a server,

iii) authenticating the client by producing an anonymous signature andopening and maintaining an anonymous authentication session with aserver, and

iv) selectively allowing contact between the server and the anonymouscertification authority to revoke the anonymity of the client using thesignature provided in step iii).

For a user client, step i) advantageously consists in recovering fromthe anonymous certification authority, constituting a trusted thirdparty, information (a public key and a certificate) enabling it tocalculate anonymous signatures. Any server or resource can verify thesesignatures without the real identity of the user being revealed to it. Avalid signature guarantees to the resource or server that it can, ifnecessary, recover the real identity of the user by interrogating thetrusted third party.

Thus the present invention proposes a complete and global solution that:

Guarantees the anonymity of clients: the invention is based on strongauthentication mechanisms that preserve the anonymity of clients.

Maintains an authentication session effectively: the authenticationsession maintenance mechanism that the invention proposes does notnecessitate any calculation on the client side. All the necessaryinformation is calculated during the authentication stage.

Makes clients responsible for their actions: the invention guaranteesnon-repudiation because the server can revoke the anonymity of a clientat any time by interrogating a trusted third party and because theserver can prove each of the actions of a client.

The present invention also relates to a system adapted to open andmaintain an authentication session guaranteeing non-repudiation,characterized in that it comprises means adapted to implement threestages:

a first stage in which the client calculates data formed of a series oftokens of which one enables a session to be opened and the others enablethe session to be maintained,

a second stage in which the client makes a strong undertaking to theserver as to the series of tokens, and

a third stage of maintaining the session with the aid of the series oftokens.

It will be noted that in the above session opening and maintainingsystem, the client is able to produce a digital signature that is notnecessarily anonymous, although it is preferably anonymous, of course.

The documents [12], [13] and [14] describe various forms of electronicbidding. None of them teaches or suggests a session opening andmaintaining system enabling multiple successive interventions of theclient during one and the same session resulting from a single initialauthentication. In fact, in the systems defined in each of the abovedocuments, bidders send only one amount or item of data.

BRIEF DESCRIPTION OF THE DRAWINGS

Other features, objects and advantages of the present invention willbecome apparent on reading the following detailed description andexamining the appended drawings, which are provided by way ofnon-limiting example and in which:

FIG. 1 shows the general architecture of relational means employed bythe present invention,

FIG. 2 is a flowchart of the method of the present invention,

FIG. 3 is a diagram of a strong identification process,

FIG. 4 is a diagram of an anonymous certification process,

FIG. 5 is a diagram of a revocable anonymity blind signature process,

FIG. 6 is a diagram of a group signature process,

FIG. 7 is a diagram of application of the present invention to anelectronic bidding process,

FIG. 8 is a diagram of a preparatory step of offering for sale andconsultation in the context of electronic bidding,

FIG. 9 is a diagram of one example of an article information sheet madeavailable to a visitor, i.e. a potential client, in the context of anauction,

FIG. 10 is a diagram of a step of obtaining an anonymous certificate,

FIG. 11 is a diagram of group registration, key generation andcertificate sending steps in the above context,

FIG. 12 is a diagram of a participation request step with certificationand authorization,

FIG. 13 is a diagram of the steps of initialization and then generationof tokens by two clients in the context of bidding,

FIG. 14 is a diagram of a step of participation in an auction,

FIG. 15 is a diagram of the steps of raising a bid by sending a tokenwhose index (i.e. “rank”) represents the value chosen for the increasedbid,

FIG. 16 is a diagram of a bid instruction processing step,

FIG. 17 is a diagram of processing a token received from a client andcomparing the value represented by its index with data receivedbeforehand,

FIG. 18 is a diagram of an auction conclusion step,

FIG. 19 is a diagram of steps of informing the winning bid client,losing bid clients and vendor and ending the transaction, and

FIG. 20 is a diagram of a client-server architecture for implementingthe method of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

As indicated above and as shown in the appended FIG. 1, the inventionuses three protocol entities: clients C, at least one anonymouscertification authority ACA and at least one server (i.e. “resource”)Se.

As also indicated above, the invention proposes an anonymousauthentication mechanism that is based on the use of anonymouscertificates, an economical and effective session maintaining mechanismthat guarantees non-repudiation, and a global solution combining theanonymous authentication mechanisms (e.g. group signature, anonymouscertificate) and the session maintaining mechanism to solve thefollowing problems:

User anonymity: the invention relies on strong authentication mechanismsthat preserve the anonymity of users, not only from other users, butalso from servers.

Effectiveness and portability: the authentication session maintainingmechanism that the invention proposes does not necessitate anycalculation at the user end, as all the necessary information iscalculated beforehand, during the authentication stage.

Non-repudiation: the invention guarantees non-repudiation because theserver can revoke the anonymity of a user at any time by interrogatingthe trusted third party (ACA) and because the server can prove each ofthe actions of a user.

Ergonomics: the user registers only once with a trusted third party(ACA).

The anonymous certification authority (ACA) delivers anonymouscertificates and is adapted and approved to revoke user anonymity ifnecessary. The server provides services to persons (clients) C wishingto remain anonymous, but whose anonymity can be revoked if necessary. Aclient obtains an anonymous certificate with the objective ofauthenticating himself anonymously and then maintaining a session with aserver.

A preferred implementation of the method of the invention comprisesessentially four steps.

Step 1: identification. The client C registers with a trusted authority(this authority may be either the anonymous certification authorityitself or some other certification authority). For the user, this stepconsists in providing personal information (name, forename, address,etc.). Several options are available for this. For example, the clientcan register either on-line, by filling in an electronic form, or byphysically going to a specific place. The trusted authority verifies theidentity of the client and some or all of his personal information,stores that information for future use, and supplies to the client meansto enable him to authenticate himself to the ACA (for example alogin/password or a certificate). Note that throughout the remainder ofthe protocol the client does not at anytime have to supply his personalinformation.

Step 2: authentication to the ACA. This step involves the client and theACA. The client authenticates himself to the ACA using the strongauthentication means obtained in step 1. The ACA supplies in returnmeans for producing an anonymous signature and holds the means forlinking the client (i.e. the physical person known to it as a result ofthe strong authentication) at any time to any signature emanating fromthe client.

Step 3: anonymous authentication with the server. This step involves aserver and a client. The client wishes to maintain a session for accessto the services that the server offers and to this end must inform theserver that he has authenticated himself to the ACA using the strongauthentication process. The client wishes to remain anonymous vis-à-visthe server and other potential clients. The object of this step is toopen a session with the server and to carry out a certain number ofcalculations so that the session may thereafter be maintained veryquickly.

Thus this step is divided into three stages. The first stage enables theclient to calculate data constituting a series of tokens, one of thetokens enabling him to open a session and the others enabling him tomaintain the session. The second stage enables the client to give astrong undertaking to the server on the basis of the series of tokens.The third stage consists of maintaining the session using the tokens.

Note 1: In certain cases (for example if the anonymity service is billedto the server), the ACA may require authentication of servers seeking tooffer the anonymity service to their users. To this end, the ACA may beable to demand authentication of the servers before supplying ananonymous certificate to the user and/or before revoking anonymity.Servers must therefore register themselves with the ACA beforehand. Tothis end, each server submits a request for affiliation to the ACA,which evaluates the proposal (according to criteria that it hasestablished) and decides whether or not to accept the proposal.

Note 2: The first two stages necessitate a dialogue between the user andthe ACA, in the first stage, and between the user and the server, in thesecond stage, and are therefore typically effected using a web browseror an application hosted on the station of the client. However, sincethe series of tokens is precalculated during the authentication stage,it can be onboard a portable terminal (mobile telephone, PDA, etc.). Theuser can therefore authenticate himself to the server using the browseror an application and then maintain the authentication session usinganother type of terminal.

All the tokens are for one-time use and are strongly interdependent.They can be calculated only by the client and cannot be falsified.Anyone, and therefore the server, can verify the dependency (and thusthe source) of the tokens.

Thus, during a first time period, while opening a session, the clientcalculates a series of tokens. The token generation algorithm is basedon the use of two cryptographic primitives: a hashing function and arandom number.

A hashing function Ho has the following properties:

H(M) operates on a message M of arbitrary length

The result h=H(M) has a fixed length l

Given M, it is easy to calculate h

Given M, it is difficult to find another message M₀ such that H(M)=H(M₀)

Hashing functions include the MD5 (Message Digest 5) function and theSHA (Secure Hash Algorithm) function. The SHA function produces anoutput comprising 160 bits called an abbreviated message.

To initialize the series of tokens, it is necessary to generate a randomnumber from which the hashing function calculates the tokens. The randomnumber must be cryptographically secure, i.e. the probability of asuccessful exhaustive search for it must be practically zero.

The hashing function applied to the random number W₀ produces a resultW₁ (i.e. a first token) to which the hashing function is applied againto obtain a second token W₂, and so on to obtain n tokens:H(W₀)=W₁, . . . , H(W_(n−1))=W_(n)

The series of tokens is therefore (W_(n), W_(n−1), W_(n−2), . . . , W₁,W₀). Because of the properties of hashing functions, it is easy,starting from W₀, to calculate any W_(i) (for i from 1 to n), whereas itis impossible in practice to find W₀ from W_(i) (for i from 1 to n).

In a second time period, the client uses the strong anonymousauthentication means obtained in step 2 to produce an anonymoussignature of the initialization token W_(n), the signature enabling theserver to authenticate the client (it can verify the validity of thesignature and therefore be convinced of the rights of the client it isfaced with). In this way the client opens up an anonymous session withthe server and can maintain the session using the series of tokens. Thetoken W_(n) is stored by the server and is used to verify the validityof the other tokens (and thus of the session).

Note: During the anonymous authentication stage, certain information maybe associated with the initialization token (for example, the face valueof a token). This information constitutes session information and isused to describe the semantics associated with each token. A tokentherefore enables a server to find out the identity of the sender andalso the session information.

During the session, the server wishes to be sure of being able todetermine the physical identity of the client it is faced with inaccordance with the principle defined in the fourth step. Moreover, thatauthentication must be carried out quickly. To this end, on each newauthentication, the client simply sends a token from the list calculatedpreviously: W_(n−1), then W_(n−2), W_(n−3), etc. To continue thesession, the client transmits the tokens in the order from n−1 to 0.

As a general rule, if the result of h(W_(n−1)) is equal to W_(n) thenthe authentication is accepted. The server is capable of verifying thelink: the token W_(i) received is compared with the tokens of all theclients present in the database. Accordingly, to find in the databasethe W_(k) linked to the W_(i) received, the following formula is used:h^(l)(W_(i))=W_(k) (this relies on the fact thath²(W_(n−2))=h(h(W_(n−2)))=h(W_(n−1))=W_(n)). If the server finds thetoken W_(k) in its database, it agrees to continue the session and thetoken W_(i) replaces the token W_(k) for the next verification. If not,the token does not belong to a client and authentication is refused.

During the various authentications that are carried out during asession, the server therefore always knows how to link a token (and thusthe session) to the anonymous signature effected at the time the sessionwas opened.

Step 4: This uses a server and a trusted authority. The server holds asignature that it knows emanated from a client who has been stronglyidentified to the ACA. If it requires to, it can therefore send thesignature to the ACA, which has the means to discover the physicalidentity of the signatory (cf. first step) and to supply thatinformation to the server. The latter can therefore obtain the physicalidentity of the client who produced the signature and the series oftokens it received during the session.

In a variant in which the server does not know the identity of theclient at any time, once the ACA has revoked anonymity, it contacts theclient involved personally and terminates the session appropriately.

In some cases, the right to effect an anonymous signature istime-limited (for example linked to only one session). In this case, theclient must strongly authenticate himself to the ACA for each session(i.e. for each series of tokens).

The number of sessions linked to an undertaking is time-limited becausethe series of tokens is finite. Once the last token has been sent, theclient must obtain a new series of tokens with the aid of the server andmust anonymously sign the initialization token.

The step 3 can be used on its own to open and maintain an authenticationsession effectively. Thus a client can strongly authenticate itself tothe server (but without anonymity in this instance) and maintain asession, very quickly, using the series of tokens that it has calculatedbeforehand. This approach further guarantees non-repudiation.

Specification of the Token Mechanism

Initialization Token

The first token a client sends to a server is called the initializationtoken and opens a session. It is linked to the authentication of theclient on the basis of a signature and to the session information. Thusthe initialization token fixes, by association, in a message sent by theclient to the server, the proof of authentication and the sessioninitialization parameters.

In the case of a bidding application, as described hereinafter, thetoken mechanism is used during the stage of participating in an auction.A client requests to participate in the auction by sending a messagemade up of the initialization token associated with the parameters ofthe auction, for example the identifier of an article, the current bid,and the value of the bid increment. This message is signed. The clientalso sends, in this request to participate, means enabling the server toverify the signature (message, public key, certificate, etc.) and thusto authenticate the client, as a function of the signature mechanismused. Signature mechanism specifications are described hereinafter.

If the authentication of the client by the server is valid, the bidserver stores the initialization token and the data sent by the clientin the request to participate.

Session Maintaining Tokens

In the case of bidding, if the server authorizes the client toparticipate in the auction after receiving the initialization token, theclient can then submit raised bids by sending the server the successivetokens, and nothing but the tokens, because each bidding instructionfrom the client is reflected in the sending of a token with no otherinformation or signature. Using the information stored with theinitialization token, the server can authenticate the instruction byassigning the token to its proprietor client and calculating its value.Accordingly, each token the server receives is compared with all thestored tokens. Because of the interdependency of the tokens, a new tokenreceived by the server can correspond to only one token in the database.The server retrieves the information on the client and on the articlelinked to a received token by matching it to a single stored token. Bythis method, the token mechanism can be applied to bidding byestablishing calculation rules.

On the client side, the calculation of the index i of the token W_(i)for a raised bid (upbid) is based on the current bid (maxbid) of thearticle and the bid increment (inc) for the article. The followingformulae may be used:upbid=maxbid+incj=(upbid−startbid)/inci=totalnumberoftokens−j

On the server side, the token W_(i) received is compared with the tokensin the database. The following formulae may be used to retrieve thetoken and calculate its value:

the formula for finding W_(k) in the database is:h ^(l)(W _(i))=W _(k)

the formula for calculating the value of W_(i) is:W _(i) =bidofW _(k)+(l*inc)Specification of Initialization Token Signature Mechanism

Signing the initialization token enables a session to opened and thesignature can be anonymous or not, as appropriate. The client has aprivate (secret) key SK, a public key PK and a certificate (anonymous ornot). He uses his private key SK and a cryptographic algorithm (forexample an RSA, DSA or group signature algorithm) to sign a message madeup of the initialization token W_(n) and session information(session_data). In this way he obtains a signature S-Sigsk (W_(n),session_data) and sends it to the server with the message, his publickey PK and the certificate C that links that public key to his identity.

FIG. 3 is a diagram of the initialization token signature protocol.

Anonymous Signature Mechanism Specification

Anonymous Certificate

During the second step, the client C creates a pair of keys (for exampleRSA keys) comprising a public key PK and a private (secret) key SK. Hekeeps the private key secret and sends the public key PK to the ACA inorder to obtain, during a strongly authenticated session, a certificateAC=Sig_(ACA) (PK, Pseudo) for that key linked to a pseudonym chosen bythe ACA and/or the client. That pseudonym can be the result ofencrypting the real identity of the client accompanied by a randomnumber. It is therefore easy for the ACA to revoke the anonymity of theclient by decrypting the pseudonym to obtain the identity of the client.The ACA stores the link between the client and his pseudonym so as to beable to revoke anonymity subsequently.

Note: An anonymous certificate can generally be used to link a pseudonymto a public key. However, depending on the context, it may also includeother information limiting the scope of the certificate (e.g. theidentifier of the server, the identifier of a session, a validity date,the IP address of the client, the authentication context, etc.).

For the client, the step of signing the initialization token involvesusing his private key PK (the signature is therefore an RSA signature).The message consists of the initialization token W1000, the signature S,the public key PK and the certificate linked to the pseudonym AC+Pseudo.The server therefore opens a session with a client that it knows only bya pseudonym and verifies that the client has strongly authenticatedhimself to the ACA by means of the certificate AC and that the certifiedpublic key PK belonging to the pseudonym can be used to verify thesignature of the initialization token.

Anonymity is revoked if the server supplies the certificate (or thepseudonym) to the ACA, which can identify the client to whom thepseudonym corresponds and therefore the client who effected thesignature.

FIG. 4 shows the details of the anonymous certificate protocols.

Note that to obtain beneficial anonymity it is necessary to change thecertificate (and therefore the signature key pair) for each session. Itis therefore necessary for the client to connect to the ACA for eachsession.

Note: If the client wishes to connect to a plurality of serversbenefiting from the services of the ACA, he has two options: either theACA supplies a single (universal) certificate for all servers, in whichcase it is possible to trace the pseudonym of the client over all sites(it is not known who he is but it is known what he has done on each ofthe servers), or the ACA supplies a certificate for each server, inwhich case the universal nature of the certificate is lost but it isthen impossible to trace the same client over more than one server.

Each server supplies the client with an identifier that is forwarded tothe ACA. The latter therefore knows that it has supply a certificate fora particular server to a particular client and will therefore not supplytwo certificates.

Note: Similarly, if the client has two machines from which he wishes toaccess the server (for example one machine at work and another machineat home), he must be able to obtain two different certificates from theACA.

Revocable Anonymity Blind Certificate

A portion of the method of the present invention may be similar to arevocable anonymity blind certificate.

The concept of a blind signature scheme was introduced by Chaum atCrypto '83. A blind signature scheme is a protocol involving twoentities, a signatory and a user. It enables the user to obtain asignature of a signatory on a given message without the signatoryfinding out anything at all about the message.

The revocable anonymity blind signature model is made up of a pluralityof users, a signatory, a recognized authority, for example a judge, andtwo protocols:

A signature protocol used between the signatory and the user.

A recovery protocol used between the signatory and the judge.

Using the signature protocol, the sender obtains a valid signature onthe message of his choice in such a way that the signatory cannot linkthe protocol and the message/signature combination. There are two typesof revocable anonymity blind signature, depending on the informationthat the judge receives from the signatory under the second protocol:

Type 1 revocation: using the portion of the protocol coming from thesignatory, the judge provides information that enables the signatory (oranyone else) to recognize the message (i.e. the judge can retrieve themessage).

Type 2 revocation: using the message and the signature, the judgeenables the signatory effectively to retrieve the user or the portion ofthe protocol corresponding to the signature.

For revocable anonymity blind signature (also known as “fair blindsignature”) scheme examples, see the documents [6], [7], [8], [9], [10]and [11].

In the case of the invention (type 2 revocation), the ACA is thesignatory and the server is the judge. The client is the user. In thefirst step, the client creates a pair of keys (for example RSA keys)comprising a public key PK and a private (secret) key SK, keeps theprivate signature key secret and sends the public key PK to the ACA inorder to obtain, during a strongly authenticated session, a revocableanonymity blind signature BC of that key (under the protocol forobtaining a certificate). The blind signature corresponds to hisanonymous certificate. The ACA stores the means for revoking theanonymity of the signature. In FIG. 5, the blind signature is denotedBC=BSig_(ACA) (PK).

For the client, the initialization token signature step (under the tokensignature protocol) consists in using its private key PK to sign, andthe signature is therefore an RSA signature. The message consists of theinitialization token W1000, the signature S, the public key PK and theanonymous certificate BC. Thus the server verifies that the client hasbeen strongly authenticated to the ACA using the anonymous certificate(it verifies that the signature BC does come from the ACA), and that thecertified public key PK can be used to verify the signature S of theinitialization token.

Anonymity is revoked if the server supplies the anonymous certificate BCto the ACA, which can tell the time at which it produced the signature(under the anonymity revocation protocol) and thus to whom it suppliedit.

FIG. 5 is a diagram of the details of the revocable anonymity blindcertificate protocols.

Note that in this case it is necessary to obtain a blind signature foreach session, and that it is therefore impossible to link two sessionsof the same client. The client must therefore connect to the ACA beforeeach session starts.

In the situation of a plurality of servers or a plurality of machines byclient, the same problem and the same solutions are encountered as withan anonymous certificate.

Group certificate

The invention may also make use of a group signature.

A group signature enables the members of a group to produce a signaturethat the verifier recognizes as having been produced by a member of thegroup, although without being able to tell which member. However, atrusted authority can revoke this anonymity at any time and thereforereveal the identity of the signatory. Such signatures often cannot becorrelated: it is impossible to determine if two signatures wereeffected by the same person.

In any group signature scheme, the group is assigned a single grouppublic key and each member of the group is assigned an identifier and aprivate key specific to him. Using his private key, a group member canapply to a message of his choice a group signature which can be verifiedby any entity using the group public key. Verification tells the entityonly that the signature was applied by a group member, but gives noinformation as to the identity of the member who signed. On the otherhand, the trusted authority has supplementary information enabling it toretrieve the identity of the member concerned, and therefore to revokehis anonymity at any time (this process is referred to as the trustedauthority “opening” the signature). For group signature schemes see thedocuments [1], [2], [3] and [4].

In the situation of the invention, the ACA is the trusted authority. Inthe first step, a client registers in a group with the ACA byinteracting with it to obtain a member certificate GC under the memberregistration protocol. The ACA retains the means to open a signature ifnecessary.

The step of signing the initialization token W1000 consists in producinga group signature S=Sig_(GP) (W1000) of that element (under the groupsignature protocol). Thus, the signatory is anonymous within the group.The server has the means to verify that a signature was applied by amember of the group (under the group signature verification protocol)but without being able to tell which member that was.

Finally, as the trusted authority, the ACA has the means to open thesignature (under the group signature opening protocol) to revoke theanonymity of the signatory and divulge his identity.

FIG. 6 is a diagram of the details of the group certificate protocols.

Note that, because group signatures are anonymous and cannot be linked,it is not necessary to register with the group for each session.Registering with the group entitles the client to apply as many groupsignatures as he wishes without anyone being able to link two of hissignatures. The single certificate may be used with a plurality ofservers with no risk of it being possible to trace the client.Similarly, a client having several machines does not need to obtainseveral certificates.

Note: An interesting property of approaches that are based on groupsignatures and on blind signatures is that they enable the certificategeneration functions and the anonymity revocation powers to be dividedbetween two or more authorities. According to this principle, it is notpossible to revoke the anonymity of a user unless this is authorized byall the authorities. This process is less natural in the case ofanonymous certification.

Implementation Example

Application of the present invention to electronic bidding will now bemore particularly described.

The application described here to illustrate the method of the inventionis from the field of e-commerce in the form of auction sales via theInternet.

The selling principle adopted is that of conventional auctions, wherebya plurality of bidders submit increasing bids for an article during aspecific time period. This implementation is based on client-serverarchitecture Java technologies (applet, servlet, jsp) and a relationaldatabase management system.

1 Problem Specific to Bidding Solved by the Method

1.1 Object

The method offers an innovative solution to making electronic biddingsecure and means that transactions may be carried out in totalconfidence.

At present, high-value on-line bids do not offer sufficient security toparticipants keen to preserve their anonymity. The organization ofpublic auctions involving bids of several thousand or even severalmillion Euros calls for new mechanisms.

The cryptography used in the context of the invention meets theapplicable objectives. To preserve confidentiality, informationtransmitted is unintelligible to persons external to the transaction.

The method provides non-repudiation to guarantee that the client is notable to deny having made an increased bid, ensures the integrity of thedata exchanged, and enables a user to be identified by authentication.

Moreover, the method is fast, in order to act on bid instructions inreal time.

1.2 Innovation and Technical Advantages of the Method Applied to Bidding

The mechanism of signed tokens with anonymity is suited to bidding. Withthis method, a purchaser can be authorized to participate in biddingwithout risk of fraud linked to disclosure of his identity. No person isable to pass himself off for someone else and only registered andauthorized members can participate in bidding.

The login/password system known at present is very widely used but doesnot offer complete guarantees. A computer can easily capture informationtransmitted in clear over the Internet and this enables hackers to stealpasswords. Although a protocol such as the SSL protocol guards againstthis type of attack, it is not able to combat attacks based ondictionaries of passwords, which make it easy to break passwords thatare too short and too simple.

The characteristic feature of the tokens used in the method of theinvention is their one-time use. A token can be used for only one bidinstruction and does not reveal any information on its user. It merelyverifies that the request transmitted belongs to a specific user. Here,a bid instruction identified by a one-time password is certified tobelong to a particular purchaser for a single amount.

The client C sends tokens to the bid server Se to bid for a product. Afirst token, denoted W1000 for client 1 and X1000 for client 2,presented at the start of bidding serves as an initialization token andprovides a means of proof that remains valid for the remainder of theauction (see FIG. 7). Based on this token mechanism, the basic principleis to sign the first token sent to register the request from a client toparticipate. The method described above verifies the bidding tokenstransmitted against the initialization token.

Subsequent tokens represent higher bids. For example, if a client(client 1) participates in bidding with a starting bid of 1000 units andan increment of 100 units, he can increase the bid to 1100 units bytransmitting a token (W999). To raise his bid to 1400 units to beatanother purchaser who has bid 1300 units, he has to reveal the tokencorresponding to 1400 units, i.e. the token W996.

FIG. 7 is a diagram of this process.

2 Modeling the System

2.1 General Scheme

The auction application uses three entities defined above:

an anonymous certification authority (ACA) on an anonymity server (SA);

a service provider server Se, here a bid server;

a client C.

In the present application there is also a certificate server (SC) whichsupplies a strong authentication certificate.

The main functions of the electronic bidding system are:

Preparatory stage: this consists in offering for sale, viewing andobtaining an anonymous certificate;

Bidding stage: this consists in requesting and verifying participationin a sale, bidding, and verifying bidding with a view to acquiring anarticle;

Conclusion stage: this consists in terminating the bids, validating awinning bidder and identifying the winning bidder by revoking hisanonymity, and closing the sale.

Each of the above functions is described in detail hereinafter.

2.2 Offering for Sale and Viewing

FIG. 8 is a diagram of this function.

Execution stage: preparatory;

Security level: assure authenticity of bid server;

Precondition: known bidding sites;

Objectives: find out articles offered for sale;

Main actors: visitor, vendor, administrator;

Typical scenario: Mr. Martin is an art collector who decides to acquirea work offered for sale on a bidding site. He logs onto the site andrequests to view the catalogue of articles offered for sale. Of thosearticles, he is more particularly interested in a photograph entitled“Regards” being sold by Mr. Vendor and whose starting price is 600Euros. He then clicks to obtain the article information sheet, as shownby way of example in FIG. 9.

2.3 Obtaining Anonymous Certificate

FIG. 10 is a diagram of this function.

Execution stage: preparatory (this represents the first step of themethod);

Security level: obtain anonymity with group signature;

Constraint: double certification;

Precondition: strong authentication (step 1 of the method), selectanonymity server (SA);

Objectives: authentication in order to participate in an auctionanonymously;

Main actors: visitor and SA;

Typical scenario: Mr. Dupond has decided to participate in the auctionsale of a work of art whose starting price is 500,000 Euros. He wishesto remain anonymous in order not to reveal his financial resources orhis interest in the type of work on sale, and he does not want anyone tofind out that he is the new owner if he submits the winning bid.Remaining anonymous despite signing is made possible by the groupsignature feature. Mr. Dupond therefore uses a certification authoritydelivering a group signature. He registers with a group that verifieshis identity before supplying him with the means for creating keys andregistering him as a member. FIG. 11 is a diagram of this process.

2.4 Request to Participate with Certificate and Authorization

FIG. 12 is a diagram of this function.

Execution stage: bidding (this is part of the third step of the method);

Security level: certificate and signed applet for generating bid tokens;

Precondition: for client, to have a certificate, to have selected anarticle, to have authorized loading of signed applets; for bid server,to have obtained means for verifying an anonymous authentication (secondstep of the method);

Objectives: participating in an auction;

Main actor: client;

Typical scenario: to participate in bidding, Mr. Dupond submits hisrequest by means of a signed token. This first token (W1000 for Mr.Dupond or X1000 for another client (see FIG. 13)), serves as aninitialization token and provides a means of proof that remains validfor the remainder of the sale. This first token is generated and signedby the client with his private key using an applet transmitted by thebidding site. The token is associated with the parameters of the sale,the identifier of the article, the current bid and the value of the bidincrement. The signature for Mr. Dupond is anonymous because of thegroup signature feature.

2.5 Participation in an Auction

FIG. 14 is a diagram of this function.

Execution stage: bidding (this is part of the third step of the method);

Security level: token guaranteeing authenticity, integrity andconfidentiality of bid instruction;

Precondition: to be registered for auction, token to have anaffiliation;

Objectives: to submit a bid instruction to secure the sale;

Main actor: client;

Typical scenario: Mr. Martin participates in the auction sale of thephotograph that he has selected with a starting bid of 600 Euros and abid increment of 10 Euros. He is the first bidder and bids 610 Euros bytransmitting a token (W999). While he is bidding, another clientincreases the bid to 620 Euros. Mr. Martin is ready to bid higher andclicks the button to increase the bid to 630 Euros and sends the tokenwith index 997 (W997). As described above, each token corresponds to avalue calculated as a function of the starting bid and the bidincrement.

In this sale, the index 999 represents the value 610 Euros, the index998 represents the value 620 Euros, the index 997 represents the value630 Euros, the index 996 represents the value 640 Euros, etc.

FIG. 15 is a diagram of this process.

2.6 Processing of Bid Instructions

FIG. 16 is a diagram of this function.

Execution stage: bidding (this corresponds to the third step of themethod);

Security level: token assuring authenticity of client and integrity ofdata;

Precondition: to have an initialization token for bids for an article bya particular client;

Objectives: to compare bid instructions, store instructions and informof changing bids;

Main actor: client;

Typical scenario: When Mr. Martin clicks on the button to increase thebid, a token corresponding to that bid is sent to the bid server. At theserver, the token enables retrieval of the information needed for thebid instruction, i.e. its value, its proprietor (Mr. Martin) and thearticle concerned. To find out the position of Mr. Martin, hisinstruction is compared to the instructions of other clients. Mr.Martin's bid is registered and the price of the photo is updated.

FIG. 17 is a diagram of this process.

2.7 Conclusion of the Sale

FIG. 18 is a diagram of this function.

Execution stage: conclusion of the sale (this includes the fourth stepof the method);

Security level: identifying winning bidder and revoking anonymity ofwinning bidder in event of a group signature;

Objectives: to determine winning bidder and to close transaction;

Main actors: client, vendor, SA, trusted third party;

Typical scenario: When the sale has finished, the system determines ifMr. Dupond is the winning bidder or not by comparing the various bids.The bid of 800 000 Euros is the highest bid and Mr. Dupond (anonymously)secures the work of art. The other clients are informed they have lost.The vendor is informed that his article has found a purchaser. Thetrusted third party is then responsible for revoking the anonymity ofMr. Dupond and for closing the transaction in the role of intermediarybetween Mr. Dupond and the vendor.

FIG. 19 is a diagram of this process.

2.8 Remarks

Registering to participate in bidding: registration for bidding islinked to a session. It is therefore necessary to reinitialize theregistration in the event of disconnection or a change of session.

Use of certificates: strong authentication certificates and anonymouscertificates are multi-use certificates. It is therefore possible to usea certificate for a plurality of auctions without having to submit a newrequest for each auction, unless the certificate is revoked or expires.

Properties at the request of the anonymous certificate: during theconnection between a client and the anonymity server site, theconfidentiality and integrity of the information transmitted and theguaranteed anonymity of the client vis-à-vis the outside world areassured by a communication protocol, for example the SSL protocol.

Anticipation of first participation: the configuration of the technicalenvironment of the client station (signed cryptographic applet) and theapproaches for obtaining certificates call for preparation toparticipate in a sale.

3 Specification of the Bidding Application

This section describes briefly the API for the services of theapplication at the following levels:

Request for an anonymous certificate and to participate in bidding;

Checking request to participate;

Bidding;

Verification of bid;

Conclusion of sale.

Steps marked * are considered as basic in the context of the method ofthe invention.

3.1 Request for an Anonymous Certificate and to Participate in Bidding

Strong authentication with ACA*

Generate keys*

Send public key to ACA*

Obtain anonymous certificate from ACA*

Generate tokens*

Store tokens*

Sign initialization token and article id*

Transmit signed token, certificate and signed article id*

Receive confirmation

Display confirmation

3.2 Check Request to Participate

Recover means for verifying an anonymous authentication with ACA*

Receive applet data

Verify signature using resources of ACA*

Connect to database

Register token, certificate, article id data

Select max price of article in base

Send confirmation

3.3 Bidding

Update maxbid

Calculate token relative to higher price

W_(i)?

Upbid=maxbid+inc

j=(upbid−startbid)/inc

i=total number of tokens−j

Send token*

Receive response

3.4 Bid Verification

Count down sale time

Receive token (W_(i))*

Verify token (find W_(k) in base so h^(l)(W_(i))=W_(k))*

Select data from base for Wk

Select maxbid of article id

Calculate bid corresponding to received token W_(i bid of W) _(i)=bid ofW_(k)+(l*inc)

Compare maxbid to bid of W_(i)

Register bid of W_(i)(UPDATE)

Report to client on his situation

3.5 Conclusion of Sale

Detect end of bidding

Determine highest bid

Revoke anonymity*

Inform winning purchaser

Inform vendor

4 Technical Organization

4.1 Client—Server Architecture

FIG. 20 is a diagram of this architecture.

It includes a client browser, an ACA server and a bid server Se (thelatter each being associated with a specific database) adapted toimplement the steps cited above.

4.2 Prototyping Tools: Database, Application Server and Java Plug-In

The database used by the inventors to prototype this application is anOracle 8i database. Oracle is a relational database management system(DBMS) from the company of the same name. Oracle uses the StructuredQuery Language (SQL) to define and manipulate data, and this languagehas become the norm in the field of relational databases. SQL*PLUS isthe Oracle user interface enabling interactive use of SQL on aninstantiation of Oracle.

The implementation of the invention uses the Java programming languageand Java technologies. The application is managed by the IBM productWebSphere 3.5. The WebSphere Application Server is used for webtransactions and interaction. It provides a portable platform fordeployment of Java Web applications structured around the processing andexecution of servlets, JavaBeans and Java Server Pages (JSP) files. Itis an interface with the web server for managing client requestsrelating to server side resources and for routing them to theapplication server for processing. The tool used in WebSphere is theservlet engine. It executes inside the application server and managesrequests relating to servlets, Java Server Pages (JSP) files and webapplications that contain them.

The client station has been tested on a Windows system with the JavaPlug-in. That Plug-in (supplied by Sun) updates the version of the JVMof the browser (Internet Explorer or Netscape). The Java Plug-inreplaces the default Java Runtime of the browser with the Sun JRE.

Of course, the present invention is not limited to the particularimplementation that has just been described and encompasses any variantconforming to the spirit of the invention.

REFERENCES

-   [1] G. Ateniese, J. Camenisch, M. Joye, G. Tsudik. A practical and    provably secure coalition-resistant group signature scheme. In L.    Bellare, editor, Advances in Cryptology—Crypto 2000, volume 1880 of    LNCS, pages 255-270. Springer-Verlag, 2000.-   [2] S. Canard, M. Girault. Implementing group signature schemes with    smart cards. CARDIS Conference 2002.-   [3] J. Camenisch, M. Michels. A group signature scheme based on an    RSA-variant. Proceedings of Eurocrypt'98, volume 1514 of LNCS.    Springer-Verlag, 1998.-   [4] J. Camenisch, M. Stadler. Efficient group signature schemes for    large groups. Proceedings of Crypto'97, volume 1296 of LNCS, pages    410-424, Springer-Verlag, 1997.-   [5] K. Q. Nguyen, J. Traoré. An Online Public Auction Protocol    Protecting Bidder Privacy. Information Security and Privacy, 5^(th)    Australasian Conference-ACISP 2000, pages 427-442. Springer-Verlag,    2000.-   [6] J. Camenisch, U. Maurer, M. Stadler. Digital payment systems    with passive anonymity-revoking trustees. Proceedings of ESORICS'96,    volume 1146 of LNCS, pages 33-43, Springer-Verlag, 1996.-   [7] J. Camenisch, U. Maurer, M. Stadler. Digital payment systems    with passive anonymity-revoking trustees. Journal of Computer    Security, vol. 5, number 1, IOS Press, 1997.-   [8] A. de Solages, J. Traoré. An Efficient fair off-line electronic    cash system with extensions to checks and wallet with observers.    Proceedings of Financial Crypto'98, volume 1465 of LNCS, pages    275-295, Springer-Verlag, 1998.-   [9] A. de Solages and J. Traoré., Procédé de signature numérique    juste, no. 98 02197, CNET/02959, filed Fe. 24, 1998.-   [10] Y. Frankel, Y. Tsiounis, M. Yung. Indirect discourse proofs:    achieving fair off-line electronic cash. Proceedings of    Asiacrypt'96, volume 1136 of LNCS, pages 244-251. Springer-Verlag,    1996.-   [11] Y. Frankel, Y. Tsiounis and M. Yung. Fair off-line cash made    easy. Proceedings of Asiacrypt'98, volume 1514 of LNCS.    Springer-Verlag, 1998.-   [12] KOBAYASHI K; MORITA H. Efficient sealed-bid auction by using    one-way functions. IEICE Transactions on fundamentals of    electronics, communications and computer sciences. Institute of    Electronics Information and Comm. Eng., vol. e84-A, no.1, 1 January    2001 (2001-01-01), pages 289-294.-   [13] SUZUKI K; KOBAYASHI K; MORITA H. Efficient sealed-bid auction    using hash chain. Information Security and Cryptology—ICISC 2000.    Third International Conference. Proceedings (lecture notes in    computer science, vol. 2015, Spring-Verlag), 9 Dec. 2000    (2000-12-09), pages 183-191.-   [14] BYOUNGCHEON LEE; KWANGJO KIM; JOONGSOO MA. Efficient public    auction with one-time registration and public verifiability.    Indocrypt 2001, Second International Conference on Cryptology in    India, 16-20 Dec. 2001, pages 162-174.

1. A method of accessing a service with authentication and revocableanonymity, comprising the steps of: i) identifying and registering aclient and providing the client with means for authenticating the clientto an anonymous certification authority; ii) authenticating the clientto the anonymous certification authority using the means provided instep i) and supplying the client with an anonymous certificateassociated to a public key and configured to enable the client toauthenticate the client anonymously to a server; iii) the clientcalculating data formed as a series of tokens, wherein an initializationtoken of the series of tokens is configured to enable an authenticationsession to be opened and tokens of the series of tokens other than theinitialization token are configured to enable the authentication sessionto be maintained; iv) authenticating the client by producing ananonymous signature of the initialization token, the signatures beingobtained using a private key associated with said public key and openingan anonymous authentication session with the server, wherein saidanonymous signature is a unique signature used for said authenticationsession; v) maintaining the anonymous authentication session with theaid of the series of tokens, thereby enabling the server to prove eachof the actions of the client; and vi) selectively allowing contactbetween the server and the anonymous certification authority to revokethe anonymity of the client using the anonymous signature provided instep iv.
 2. The method according to claim 1, further comprising:effecting communication between the anonymous certification authorityand the server, before the authenticating of the client to the anonymouscertification authority, whereby the server presents to said anonymouscertification authority a request to obtain means enabling verificationof the anonymous authentication supplied by a client.
 3. The methodaccording to claim 1, wherein each of the tokens of the series of tokensis configured for one-time use and each of the tokens of the series oftokens is strongly interdependent.
 4. The method according to claim 3,wherein a first token W_(i) of the series of tokens is obtained byapplying a hashing function H to a random number, a second token W_(z)of the series of tokens is obtained by applying the hashing function tothe first token obtained, and so on until a token of rank n of theseries of tokens defines the initialization token W_(n) as:H(W ₀)=^(W) ₁ H)(W _(n−1))=W _(n).
 5. The method according to claim 4,wherein on each new authentication the client sends the server a tokenof the series of tokens of at least one unit lower rank than thatpreviously used.
 6. The method according to claim 4, wherein on each newauthentication the client sends the server a token W_(i) of the seriesof tokens whose rank (i) is representative of a value of an operation.7. The method according to claim 6, wherein the rank is representativeof a number of bid increments.
 8. The method according to claim 4,wherein the steps are applied to bidding and steps of the clientsubmitting an increased bid are effected by sending successive tokens oflower rank.
 9. The method according to claim 1, wherein the tokens ofthe series of tokens are calculated using two cryptographic primitives.10. The method according to claim 9, wherein the two cryptographicprimitives are a hashing function and a random number.
 11. The methodaccording to claim 1, further comprising using a group signature byassociating a plurality of identifiers and respective private keys witha single group public key.
 12. The method according to claim 11, whereina power to revoke anonymity is shared between two or more authorities.13. The method according to claim 1, wherein the anonymous signature isa blind signature.
 14. A system adapted to open and maintain ananonymous authentication session with revocable anonymity, the systemcomprising: an identifier configured to identify and register a clientand to provide the client with means for authenticating the client to ananonymous certification authority; an authentication device configuredto authenticate the client to the anonymous certification authorityusing the authenticating means and to supply the client with ananonymous certificate associated to a public key and configured toenable the client to authenticate the client anonymously to a server; acalculator configured to calculate data formed as a series of tokens,wherein an initialization token of the series of tokens is configured toenable an authentication session to be opened and tokens of the seriesof tokens other than the initialization token are configured to enablethe authentication session to be maintained; a producer for producing ananonymous signature of the initialization token, the signatures beingobtained using a private key associated with said public key and openingan anonymous authentication session with the server, wherein saidanonymous signature is a unique signature used for said authenticationsession to authenticate the client; wherein the anonymous authenticationsession is maintained with the aid of the series of tokens, therebyenabling the server to prove each of the actions of the client; andwherein selective contact is provided between the server and theanonymous certification authority to revoke the anonymity of the clientusing the anonymous signature.
 15. The system according to claim 14,wherein the calculator calculates the series of tokens based on twocryptographic primitives, wherein the two cryptographic primitives are ahashing function and a random number.
 16. The system according to claim14, wherein the system is configured to use a group signature byassociating a plurality of identifiers and respective private keys withthe public key being a single group public key.
 17. The system accordingto claim 14, wherein the unique anonymous signature is a blindsignature.
 18. The system according to claim 14, wherein power to revokeanonymity is divided between two or more authorities.